Comments
-
You would need a switch to act as a "tagger". Basically... in this testing environment you want it so that the AP is plugged into a switch port that forces a tag onto ALL the traffic sent from the AP, whilst you config & test it. (if you insist in testing in this dangerous way.) Because if your AP is "open", that means any…
-
nope , it's crystal clear..... VLAN's work under IP, it would be a nonsense to try and put the car wheels in the car then drive it. you would need some sort of IP signalling mechanism. to sit in the IP & re-construct the L2 flag . at the other end. And since you need to distinguish between networks, to route them NAT is a…
-
What it means , is that if i have a network vlan for switch /AP maintenance on a remote network, i have to strip the vlan from it before putting it over the vpn which means it is on vlan 1 by default/untagged I then have to "nat" it, since we cannot have the same network at both ends, so after natting it I have to ensure…
-
But that still puts them inside the same subnet and subject to the monitoring associated with it. Then there are issues related to DHCP & DNS.... since the server FQDN has to be resolved internally by the DNS. which means including internal DNS servers or setting up a shed load of "special" rules to resolve external DNS…
-
Generally you have to be a bit careful... when a DHCP request is started the device goes out with an IP address of 0.0.0.0 broadcast..... Therefore ANY DHCP server that gets the request in first, and that the client can see wins. so you have to ensure the clients are hard partitioned as to which network they can see,…
-
It's not a smart move...... Use NAT..... You will get masses of garbage windows packets going over your network , that does not specifically need to. also you end up with problems of broadcast packets.... and don't even get me started about multi site DNS & DHCP..... I run something similar between multi countries. Setup a…
-
well you need to give more information because it works ok on the mac
-
The devices involved in this ARE sonicwalls. all 3 BUT, the sonicwalls also have to connect to NON sonicwall devices, HOWEVER they are not part of the spoke to spoke path. the issue is that sonicwall will not allow two types of VPN on the same WAN subnet, even if there are multiple ips in that subnet. so for example if i…
-
No there are no over lapping subsets. and NO i'm not trying to go spoke->hub->spoke, that is EASY. I want to go spoke to spoke, without adding another damned leased line The overlapping subnets occurs if you try to assign a virtual interface to a wan as a way of adding another ip address. When building VPN you can ONLY…
-
Wont work due to the sonicwall...... 1.you cannot have multiple VPN type setups on the same external peer address at other end (site to site & tunnel interface) which we need since not every site world wide is using "sonicwall", preventing "tunnel int." even if you have multiple ip addresses on a zone, the stupidity that…
-
This is NOTHING like the same thing. clients are easy since they appear in the subnets of a local firewall and the routing takes care of it. there is no duplicate routing/ split routing.
-
You mean like faster than 2014 & 2016.......... when I initially asked.... oh and .. and 2020.. before this gets actioned... i''l be retired or hopefully off your kit that and the other "RFE" (bugs) that need fixing.....
-
Yep.. but the problem is "some" countries aggressively block "DDNS" Been there done that..... it's so "aggressive" that , the licensing & cloud backups won't work.... I'd thought about writing my own DDNS system, but sadly the sonicwall is "pre-fixed" to a set number of systems..... if it were editable for the "callout"…